Just Call Me Internet

home *** CD-ROM | disk | FTP | other *** search

/ Just Call Me Internet / Just Call Me Internet.iso / docs / ascii / atarinet / anetpoly / anetpol.txt

Wrap

Text File | 1993-02-10 | 37.9 KB | 864 lines

AtariNet Policy - Draft Sept 12, 1992 This is a draft of a proposed policy for AtariNet. 1 OVERVIEW -------------- This document establishes the policy for sysops who are members of the AtariNet organization of electronic bulletin board systems. 1.1 LANGUAGE The official language of AtariNet is English. All documents must exist in English. Translation into other languages is encouraged. 1.2 INTRODUCTION AtariNet is an amateur electronic mail system and is not a common carrier or a value-added service network and is a public network only in as much as the independent, constituent nodes may individually provide public access to the network on their system. In order to provide compatibility with the majority of existing networks, AtariNet has been structured on 'FidoNet Technology' and, as such, makes large use of associated managerial and structural procedures whereby MultiNet operation and decentralized management provide the structure and control. This document describes the procedures which have been adopted to manage the network. 1.3 GEOGRAPHY There is no "true" need to assign nodes within the United States to a Host in their own state as in-state long distance calling is more expensive than out of state calling. This may also be true in other countries and this document will be updated accordingly. 1.4 NODELISTS The nodelist is a file updated weekly which contains the addresses of all recognized AtariNet nodes. This file is regularly made available by the Zone Co-ordinator on a weekly basis. To be included in the nodelist, a system must meet the requirements defined by this document. The full list as published by the Zone Co-ordinator is regarded as the official AtariNet nodelist, and is used in circumstances as determination of eligibility for voting. 2 ORGANISATION ----------------- AtariNet systems are grouped on several levels, and administration is de-centralized to correspond with these groupings. This overview provides a summary of the structure and the duties of the Co-ordinator positions. 2.1 INDIVIDUAL SYSTEMS AND SYSTEM OPERATORS The smallest subdivision of AtariNet is the individual system, corresponding to a single entry in the nodelist. The system operator (SysOp) formulates a policy for running the board and dealing with users. The sysop must mesh with the rest of the AtariNet system to send and receive mail. 2.1.1 THE BASICS As the sysop of an individual node, you can generally do as you please, as long as you observe mail events, are not excessively annoying to other nodes in AtariNet, and do not promote or participate in the distribution of pirated copyrighted software or other illegal behaviour via AtariNet. 2.1.2 TRAFFIC ENTERING AtariNet VIA A NODE A sysop listed in the nodelist entry is responsible for all traffic entering AtariNet via that system. This includes (but is not limited to) traffic entered by users, points, and any other networks for which the system might act as a gateway. If a sysop allows "outside" messages to enter AtariNet via the system, the gateway system must be clearly identified by a AtariNet node number as the point of origin of that message, and it must act as a gateway in the reverse direction. Should such traffic result in a violation of Policy, the sysop must rectify the situation. 2.1.2.1 USERS The sysop is responsible for the actions of any user when they affect the rest of AtariNet. Any traffic entering AtariNet via a given node, if not from the sysop, is considered to be from a user and is the responsibility of the sysop. 2.1.2.2 POINTS A point is a AtariNet-compatible system that is not in the nodelist, but communicates with AtariNet through a node referred to as a bossnode. A point is generally regarded in the same manner as a user, and the bossnode is responsible for mail from the point. (See section 2.1.2) Points are addressed by using the bossnode's nodelist address; for example, a point system with a bossnode of 114/15 might be known as 114/15.12. Mail destined for the point is sent to the bossnode, which then routes it to the point. 2.1.3 ROUTING MAIL You are not required to route traffic if you have not agreed to do so. You are not obligated to route traffic for all if you route it for any, unless you hold a Co-ordinator position. Routing traffic through a node not obligated to perform routing without the permission of that node may be annoying behavior. This includes unsolicited echomail. If you do not forward a message when you previously agreed to perform such routing, the message must be returned to the sysop of the node at which it entered AtariNet with an explanation of why it was not forwarded. (It is not necessary to return messages which are addressed to a node which is not in the current nodelist.) Intentionally stopping an in-transit message without following this procedure constitutes annoying behavior. In the case of a failure to forward traffic due to a technical problem, it does not become annoying unless it persists after being pointed out to the sysop. 2.1.3.1 ALTERATION OF ROUTED MAIL You may not modify, other than as required for routing or other technical purposes, any message, netmail or echomail, passing through the system from one AtariNet node to another. If you are offended by the content of a message, the procedure described in section 2.1.3 must be used. 2.1.4 USE OF CURRENT NODELIST Network mail systems generally operate unattended, and place calls at odd hours of the night. If a system tries to call an incorrect or out-of-date number, it could cause some person's phone to ring in the middle of the night, much to their annoyance and to those of civil authorities. For this reason, a sysop who sends mail is obligated to obtain and use the most recent edition of the nodelist as is practical. 2.1.5 NODE UNAVAILABILITY If your node will be down for an extended period (more than a day or two), inform your Co-ordinator as soon as possible. It is not your Co-ordinator's responsibility to chase you down for a status report, and if your system stops accepting mail it will be removed from the nodelist. If you will be leaving your system unattended for an extended period of time (such as while you are on vacation), you should notify your Co-ordinator. Systems have a tendency to "crash" now and then, so you will probably want your Co-ordinator to know that it is a temporary condition if it happens while you are away. 2.1.6 EXCOMMUNICATION A system which has been dropped from the network is said to be excommunicated (i.e. denied communication). If you find that you have been excommunicated without warning, your Co-ordinator was unable to contact you. You should rectify the problem and contact your Co-ordinator. It is considered annoying behavior to assist a system which was excommuni- cated in circumventing that removal from the nodelist. For example, if you decide to provide an echomail feed to your friend who has been excommuni- cated, it is likely that your listing will also be removed. 2.1.7 FORMING A NETWORK If there are several nodes in your area, but no network, a new network can be formed. This has advantages to both you and to the rest of AtariNet. You receive better availability of nodelists and everyone else can take advantage of host-routing netmail to the new network. The first step is to contact the other sysops in your area. You must decide which nodes will comprise the network, and which of those nodes you would like to be the Network Co-ordinator. Then consult your Regional Co-ordinator. You must send the following information: 1) The region number(s), or network number(s) if a network is splitting up, that are affected by the formation of your network. The Regional Co-ordinator will inform the Zone Co-ordinator and the Co-ordinators of any affected networks that a new network is in formation. 2) A copy of the proposed network's nodelist segment. This file should be attached to the message of application for a network number, and should use the proper nodelist format in use on AtariNet. Please elect a name that relates to your grouping. Granting a network number is not automatic. Even if the request is granted, the network might not be structured exactly as you request. Your Regional Co-ordinator will review your application and inform you of the decision. Once the request is granted, everyone in the new net must change their node numbers accordingly. The old numbers will be left intact for approximately one week. 2.2 NETWORKS AND NETWORK CO-ORDINATORS A network is a collection of nodes Uaually in a geographic area and usually defined by an area of convenient telephone calling. Networks Co-ordinate their mail activity to decrease cost. The Network Co-ordinator is appointed by the Regional Co-ordinator. 2.2.1 RESPONSIBILITIES A Network Co-ordinator has the following responsibilities: 1) To receive incoming mail for nodes in the network, and arrange delivery to its recipients. 2) To assign node numbers to nodes in the network. 3) To maintain the nodelist for the network, and to send a copy of it to the Regional Co-ordinator whenever it changes. 4) To make available to nodes in the network new nodelist files and new revisions of Network Policy Documents as they are received, and to periodically check to ensure that nodes use up to date nodelists. 2.2.2 ROUTING INBOUND MAIL It is your responsibility as Network Co-ordinator to Co-ordinate the receipt and forwarding of host-routed inbound netmail for nodes in your network. The best way to accomplish this is left to your discretion. If a node in your network is receiving large volumes of mail you can request that the sysop contact the systems which are sending this mail and request that they not host-route it. If the problem persists, you can request your Regional Co-ordinator to assign the node a number as an independent and drop the system from your network. You are not required to forward encrypted, commercial, or illegal mail. However, you must follow the procedures described in section 2.1.3 if you do not forward the mail. 2.2.3 ASSIGNING NODE NUMBERS It is your responsibility to assign node numbers to new nodes in your network. You may also change the numbers of existing nodes in your network, though you should check with your member nodes before doing so. You may assign any numbers you wish, so long as each node has a unique number within your network.You may not assign a node number to a node in an area covered by an existing network. Further, if you have nodes in an area covered by a network in formation, those nodes must be transferred to the new network. You must not assign a node number to any system until you have received a formal request from that system by AtariNet mail. This will ensure that the system is minimally operational. It is also recommended, though not required, that you call a board which is applying for a node number before assigning it a node number. You should use network mail to inform a new sysop of the node number, as this helps to ensure that the system is capable of receiving network mail. If a node in your network is acting in a sufficiently annoying manner, then you can take whatever action you deem fit, according to the circumstances of the case. 2.2.4 MAINTAINING THE NODELIST You should implement name changes, phone number changes, and so forth in your segment of the nodelist as soon as possible after the information is received from the affected node. You should also on occasion send a message to every node in your network to ensure that they are operational. If a node turns out to be offline with no prior warning, you can either mark the node down or remove it from the nodelist. (Nodes are to be marked DOWN for a maximum of two weeks, after which the line should be removed from the nodelist). You should assemble a master nodelist for your network every week and send it to your Regional Co-ordinator by the day designated. It is important that you forward this by the day specified by the Regional Co-ordinator so as not to cause a further week's delay in adding a node to the master nodelist. 2.2.5 MAKING AVAILABLE POLICIES AND NODELISTS As a Network Co-ordinator you should obtain a new issue of the nodelist every week from your Regional Co-ordinator. You must make this available to all nodes in the network. You should also obtain the most recent versions of the Policy documents that bind the members of your network, and make those available to the nodes in your network. Policies are released at sporadic intervals, so you should also inform the nodes in your network when such events occur, and ensure the nodes are generally familiar with the changes. 2.2.6 NETWORK ROUTING HUBS Network Routing Hubs may be appointed by the Network Co-ordinator, in order to assist in the management of a large network but should be avoided if at all possible so as not to cause uneccessary delays in mail routing. The exact duties and procedures are a matter for the Network Co-ordinator and the hubs to arrange, and will not be discussed here, except that a Network Co-ordinator cannot delegate responsibility to mediate disputes. 2.3 REGIONS AND REGIONAL CO-ORDINATORS A region is a well-defined geographic area containing nodes which may or may not be combined into networks. A typical region will contain many nodes in networks, and a few independent nodes which are not a part of any network. Regional Co-ordinators are appointed by the Zone Co-ordinator. 2.3.1 RESPONSIBILITIES A Regional Co-ordinator has the following responsibilities: 1) To receive incoming mail for networks in the region, and arrange delivery to its recipients. 2) To assign node numbers to independent nodes in the region. 3) To encourage independent nodes in the region to join existing net- works, or to form new networks. 4) To assign network numbers to networks in the region and define their boundaries. 5) To compile a nodelist of all of the networks and independents in the region, and to send a copy of it to the Zone Co-ordinator whenever it changes. 6) To ensure the smooth operation of networks within the region. 6) To make new nodelist files and Policies available to the Network Co-ordinators in the region as soon as is practical. 2.3.2 ASSIGNING NODE NUMBERS It is your responsibility to assign node numbers to independant nodes in your region. (Section 2.2.3 is applicable) If you receive a node number request from outside your region, you must forward it to the most local Co-ordinator for the requestor as you can determine. If you receive a node number request from a new node that is in an area covered by an existing network, then you must forward the request to the Co-ordinator of that network instead of assigning a number yourself. If a network forms in an area for which you have independent nodes, those nodes will be transferred to the local network as soon as is practical. 2.3.3 ENCOURAGING THE FORMATION AND GROWTH OF NETWORKS One of your main duties as a Regional Co-ordinator is to promote the growth of networks in your region. You should avoid having independent nodes in your region which are within the coverage area of a network. There are, however, certain cases where a node should not be a member of a network, such as a system with a large amount of inbound netmail; see section 2.2.2. If several independent nodes in your region are in a local area you should encourage them to form a network, and if necessary you may require them to form a network. Refer to section 2.1.7. Note that this is not intended to encourage the formation of trivial networks. Obviously, one node does not make a network. The exact number of nodes required for an effective network must be judged according to the circumstances of the situation, and is left to your discretion. 2.3.4 ASSIGNING NETWORK NUMBERS It is your responsibility to assign network numbers to new networks forming within your region. You are assigned a pool of network numbers to use for this purpose by your Zone Co-ordinator. 2.3.5 MAINTAINING THE NODELIST As a Regional Co-ordinator, you have a dual role in maintaining the nodelist for your region. First, you must maintain the list of independent nodes in your region. You should attempt to implement name changes, phone number changes, and so forth in this nodelist as soon as possible. You should also on occasion send a message to every independent node in your region to ensure that they are operational. If a node turns out to be offline with no prior warning, you can either mark the node down or remove it from the nodelist. (Nodes are to be marked DOWN for a maximum of two weeks, after which the entry should be removed from the nodelist.) Second, you must receive the nodelists from the Network Co-ordinators within your region. You will need to maintain a set of nodelists for each network within your region, since you cannot count on getting an update from each Network Co-ordinator every week. You should assemble a master nodelist for your region every week and send it to your Zone Co-ordinator by the day and time designated. 2.3.6 OVERSEEING NETWORK OPERATIONS You are responsible for appointing Network Co-ordinators for the nets in your region. If the outgoing Network Co-ordinator suggests a successor, you are not obligated to accept that individual, although you normally will. Similarly, you are not obligated to accept the individual selected by the members of the network in an election, although you normally will. It is your responsibility as Regional Co-ordinator to ensure that the networks within your region are operating in an acceptable manner. This does not mean that you are required to operate those networks; that is the responsibility of the Network Co-ordinators. It means that you are responsible for assuring that the Network Co-ordinators within your region are acting responsibly. If you find that a Network Co-ordinator within your region is not properly performing the duties outlined in Section 2.2, you should take whatever action you deem necessary to correct the situation. If a network grows so large that it cannot reasonably accommodate traffic flow , the Regional Co-ordinator can direct the creation on one or more new networks from that network. These new networks, although they may be within a single local-calling area, must still conform to a geographical basis for determining membership. It is your obligation as Regional Co-ordinator to maintain direct and reasonably frequent contact with the networks in your region. The exact method of accomplishing this is left to your discretion. 2.3.7 MAKING AVAILABLE NODELISTS AND POLICIES As a Regional Co-ordinator, it is your responsibility to obtain the latest nodelist and network policies as they are published, and to make them available to all Network Co-ordinators within your region as soon as is after you receive them. The method of distribution is left to your discretion. 2.4 Zone CO-ORDINATOR The Zone Co-ordinator is the "first among equals" Region Co-ordinator, and Co-ordinates the joint production of the master nodelist by the Region Co-ordinators. 2.4.1 RESPONSIBILITIES The Zone Co-ordinator has the primary task of co-ordinating the creation of the master nodelist by managing the distribution between the Zones of the Zone nodelists and for the co-ordination and distribution of Network Policies to the Region Co-ordinators. The Zone Co-ordinator is responsible for definition of new region and for negotiation of agreements for communication with other networks. ("Other network" in this context means other networks with which AtariNet communicates as peer-to-peer, not "network" in the sense of the AtariNet organizational level.) In cases not specifically covered by this document, the Zone Co-ordinator may issue specific interpretations or extensions to this policy. The Region Co-ordinator structure may reverse such rulings by a majority vote. 2.5 CHECKS AND BALANCES These levels act to distribute the administration and control of AtariNet to the lowest possible level, while still allowing for Co-ordinated action over the entire mail system. Administration is made possible by operating in a top-down manner. That is, a person at any given level is responsible to the level above, and responsible for the level below. If a person at any level above sysop is unable to properly perform their duties, the person at the next level may replace them. For example, if a Regional Co-ordinator fails to perform, the Zone Co-ordinator can replace him. To provide for checks and balances at the highest level of AtariNet, there are two exceptions to this top-down organization. Region Co-ordinators and the the Zone Co-ordinator are selected by a majority vote of the Co-ordinators at the level below. Similarly, decisions made by the Zone Co-ordinator can be reversed by the Region Co-ordinators and decisions made by a Region Co-ordinator can be reversed by the Network Co-ordinators. Decisions made by other Co-ordinators are not subject to reversal by a vote of the lower level, but instead are subject to the appeal process described in section 3.4. 3. SETTLEMENT OF DISPUTES ------------------------- The first step in any dispute between sysops is for the sysops to attempt to communicate directly, at least by netmail, preferably by voice. Any complaint made that has skipped this most basic communication step will be rejected. Filing a formal complaint is not an action which should be taken lightly. Investigation and response to complaints requires time which Co-ordinators would prefer to spend doing more constructive activities. Persons who persist in filing trivial policy complaints may find themselves on the wrong side of an excessively-annoying complaint. Complaints must be accompanied with verifiable evidence, generally copies of messages; a simple word-of- mouth complaint will be dismissed out of hand. Failure to follow the procedures herein described (in particular, by skipping a Co-ordinator, or involving a Co-ordinator not in the appeal chain) is in and of itself annoying behavior. 3.1 PROBLEMS WITH ANOTHER SYSOP If you are having problems with another sysop, you should first try to work it out via netmail or voice conversation with the other sysop. If this fails to resolve the problem, you should complain to your Network Co-ordinator and the other sysop's Network Co-ordinator. If one or both of you is not in a network, then complain to the appropriate Regional Co-ordinator. Should this fail to provide satisfaction, you have the right to follow the appeal process described in section 3.4. 3.2 PROBLEMS WITH YOUR NETWORK CO-ORDINATOR If you are having problems with your Network Co-ordinator and feel that you are not being treated properly, you are entitled to a review of your situa- tion. As with all disputes, the first step is to communicate directly to attempt to resolve the problem. The next step is to contact your Regional Co-ordinator. If your case has merit, there are several possible courses of action, including a change of Network Co-ordinators or even the disbanding of your network. If you have been excommunicated by your Network Co-ordinator, that judgement may be reversed, at which point you will be reinstated into your net. If you fail to obtain relief from your Regional Co-ordinator, you have the right to follow the appeal process described in section 3.4. 3.3 PROBLEMS WITH OTHER CO-ORDINATORS Complaints concerning annoying behavior on the part of any Co-ordinator are treated as in section 3.4 and should be filed with the next level of Co-ordinator. For example, if you feel that your Regional Co-ordinator is guilty of annoying behavior (as opposed to a failure to perform duties as a Co-ordinator) you should file your complaint with the Zone Co-ordinator. Complaints concerning the performance of a Co-ordinator in carrying out the duties mandated by policy are accepted only from the level immediately below. For example, complaints concerning the performance of Regional Co-ordinators would be accepted from Network Co-ordinators and independents in that region. Such complaints should be addressed to the Zone Co-ordinator after an appro- priate attempt to work them out by direct communications. 3.4 APPEAL PROCESS A decision made by a Co-ordinator may be appealed to the next level. Appeals must be made within two weeks of the decision which is being appealed. All appeals must follow the chain of command; if levels are skipped the appeal will be dismissed out of hand. An appeal will not result in a full investigation, but will be based upon the documentation supplied by the parties at the lower level. For example, an appeal of a Network Co-ordinator's decision will be decided by the Regional Co-ordinator based upon information provided by the Co-ordinator and the Sysop involved; the Regional Co-ordinator is not expected to make an independent attempt to gather information. The appeal structure is as follows: Network Co-ordinator decisions may be appealed to the appropriate Regional Co-ordinator. Regional Co-ordinator decisions may be appealed to the appropriate Zone Co-ordinator. At this point, the Zone Co-ordinator will make a decision and communicate it to the Regional Co-ordinators in that zone. This decision may be reversed by a majority vote of the Regional Co-ordinators. If your problem is with the Zone Co-ordinator per se, that is, the Zone Co-ordinator has committed a Policy violation against you, your complaint should be filed with your the Region Co-ordinator, who will make a decision and forward it to the other Region Co-ordinators who will vote on it. 4 INITIATION OF POLICY MODIFICATION ------------------------------------- A referendum on policy modification is invoked when a majority of the AtariNet Regional Co-ordinators inform the Zone Co-ordinator that they wish to consider a proposed new version of Policy. 4.1 ANNOUNCEMENT AND RESULTS NOTIFICATION Proposed changes to Policy are distributed using the same structure which is used to distribute nodelist files. Results and announcements related to the referendum are distributed by the Co-ordinator structure as a part of the weekly nodelist file. If it is adopted, the Zone Co-ordinator sets the effective date for a new policy through announcement in the weekly nodelist difference file. Effective date will be not more than one month after the close of balloting. 4.2 ELIGIBILITY TO VOTE Each member of the AtariNet Co-ordinator structure at and above Network Co-ordinator is entitled to one vote. (Hub Co-ordinators do not vote). In the case of the position changing hands during the balloting process, either the incumbent or the new Co-ordinator may vote, but not both. If a person holds more than one Co-ordinator position, they still receive only one vote. Network Co-ordinators are expected to assess the opinions of the members of their network, and to vote accordingly. A formal election is not necessary, but the Network Co-ordinator must inform the net of the issues and solicit input. The network Co-ordinator functions as the representative of the rank and file members of AtariNet. 4.3 VOTING MECHANISM The actual voting mechanism, including whether the ballot is secret and how the ballots are to be collected, verified, and counted, is left to the discretion of the Zone Co-ordinator. Ideally, ballot collection should be by some secure message system, conducted over AtariNet itself. In order to provide a discussion period, the announcement of any ballot must be made at least two weeks before the date of voting commencement. The balloting period must be at least two weeks. 4.4 VOTING ON A WHOLE POLICY DOCUMENT Given that Policy is intertwined and self referencing, a relatively simple change may require several alterations of the document. In order to simplify the process, balloting is done on choices between whole documents, rather than individual amendments. In the simplest case, this means voting yea or nay to a new document. If a number of alternatives are to be considered, they must be presented as whole documents, from which one is chosen. 4.5 DECISION OF VOTE A Policy amendment is considered in force if, at the end of the balloting period, it has received a majority of the votes cast. For example, if there were 350 eligible voters, 100 of which cast a vote, then at least 51 affirmative votes would be required to declare the amendment in force. In the case of multiple policy changes which are considered on the same ballot, a version must receive more than 50% of the votes cast to be consid- considered ratified. "Abstain" is a valid vote in this case, effectively being a vote for not changing the current policy as it simply increases the number of votes required to ratify the proposed change. 5 HOW TO OBTAIN A NODE NUMBER ------------------------------- You must first obtain a current nodelist so that you can send mail. You do not need a node number to send mail, but you must have one in order for others to send mail to you. The first step in obtaining a current nodelist is to locate a AtariNet bulletin board. Most bulletin board lists include at least a few AtariNet systems, and usually identify them as such. Use a local source to obtain documents because many networks have detailed information available which explains the coverage area of the network and any special requirements or procedures. Once you have a nodelist, you must determine which network or region covers your area. Regions are numbered 100,200,300,400 for now. They will always be divisable by 100. Networks are more restricted in area than regions, but are preferred since they improve the flow of mail and provide more services to their members. If you cannot find a network which covers your area, then pick the region which does. Once you have located the network or region in your area, send a message containing a request for a node number to node zero of that network or region. The request must be sent by netmail, as this indicates that your system has mailing capability. You must set up your software so that the from-address in your message does not cause problems for the Co-ordinator who receives it. If you pick the address of an existing system, this will cause obvious problems. If your software is capable of using address -1/-1, this is the traditional address used by potential sysops. Otherwise use net/9999 (e.g. if you are applying to net 123, set your system up as 123/9999). Many nets have specific instructions available to potential sysops and these procedures may indicate a preference for the from-address. The message you send must include at least the following information: 1) Your real name. 2) Your voice telephone number 3) The name of your system. 4) The city and state where your system is located. 5) The phone number to be used when calling your system. 6) Your hours of operation for netmail and BBS. 7) The maximum baud rate you can support. 8) The type of mailer software and modem you are using. Your Co-ordinator may contact you for additional information. All information submitted will be kept confidential and will not be supplied to anyone except the person who assumes the Co-ordinator position at the resignation of the current Co-ordinator. You must indicate that you have read, and agree to abide by, this document and all the current policies of AtariNet. Please allow at least two weeks for a node number request to be processed. If you send your request to a Regional Co-ordinator, it may forwarded to the appropriate Network Co-ordinator. 6 ECHOMAIL AND ECHOMAIL CONFERENCES -------------------------------------- This section sets forth policy governing Echomail within AtariNet. The basic policy of Echomail is to promote communication in Echomail Conferences in a lawful, friendly manner consistent with the general principles of AtariNet. This section applies to Echomail conferences on the "AtariNet Backbone" 6.1 GENERAL 6.1.1 PROHIBITION ON ILLEGAL ACTIVITIES Any Node which knowingly distributes or allows to be entered into Echomail conferences any messages containing or promoting illegal activities or information shall be deemed to have violated general AtariNet policy. As used in this paragraph, "illegal activities" includes activities which are a violation of civil law as well as activities which would result in criminal prosecution. 6.1.2 CENSORSHIP The use of Censorship in the passing or distribution of echomail will be considered a violation of this section and will not be tolerated. An exception to this provision shall be the deletion and not censorship of messages by any Sysop which may lead to legal action against that Sysop. No echomail shall be modified in any manner which could potentially cause duplicates. 6.1.3 OPEN ACCESS CONFERENCE This is a non-restricted conference open to all users who are willing to follow the posted conference rules. 6.1.4 INTER-NETWORK CONFERENCES Inter-Net conferences shall conform to general AtariNet policy in addition to any foreign network's provisions. Inter-Network links shall be set up according to procedures laid down in General AtariNet policy. It shall be the duty of those providing the INTER-NETWORK CONFERENCE links to remove foreign net distribution identifiers which will adversely affect the distribution of the Echomail conference while in AtariNet. The INTER- NETWORK CONFERENCE links maintained in AtariNet shall be operated in a manner not to interfere with the foreign network's distribution of Echomail. 6.1.5 SEEN-BY LINE Under the current topology (the routing structure of Echomail), SEEN-BY lines play an important part in reducing duplicate messages. The stripping of SEEN-BYs (except Inter-Network EchoGates) will not be allowed unless approved by the ZEC. 6.1.6 COUNTERFEIT MESSAGES Entering or knowingly distributing counterfeit messages shall be considered a violation of AtariNet policy enforceable under the terms of AtariNet policy. As used in this paragraph, a counterfeit message is defined as any message entered using another person's name, handle or node address with the intent of deceiving others about the true author of the message. No handles shall be used to enter messages to knowingly provoke, inflame or upset participants in a conference with the purpose of deceiving others about the true identity of the author. 6.1.7 DEFAMATORY POSTING The posting of any DEFAMATORY MESSAGE will not be tolerated and shall lead to disciplinary action under the terms of General AtariNet policy. The posting of substantiated facts shall not be considered a violation under this section. 6.1.8 ADDING OR REMOVING CONFERENCES FROM THE MAINSTREAM In order to add an Echo to the AtariNet backbone, you should first leave a message in the A_Echo area with your idea. A total of 5 Sysops and 2 Hosts must request it in order for it to be placed on the backbone. Note that the 2 Hosts count as Sysops also. 6.1.9 MESSAGE STANDARDS Until the adoption of a superceding standard, the following Echomail message standards will apply: a) Eight-bit characters (ASCII 128-255) and non-printing low-order codes (ASCII 2-31) are prohibited, except 8Dh(soft <CR> character). This is not intended to discourage participation of foreign zones or networks, which may permit said characters. Any echomail processor should pass information exactly as it was received, without stripping any non-standard characters. b) Origin lines are limited to 79 characters including the required ending of a proper network address (i.e. Zone:Net/Node.Point with zone and point being optional). c) Tear lines are limited to 35 characters including the required "--- " lead-in. These may ONLY contain packer or editor program identification. Tear lines for message editors are discouraged. If an editor adds a tear line, it should also add an origin line to avoid multiple tear lines. d) "Extra" origin lines (ZoneGating) are to be limited to essential information only. This consists of the required lead-in plus the network name "Gateway" and optionally the software ID followed by a Zone:Net/Node address. e) SEEN-BY addresses must be in sorted order. Multiple AKA's or other network addresses are not allowed in SEEN-BY lines. 6.1.10 MODERATORS All echos on the AtariNet backbone will have a moderator. If you are the person who suggested an echo in A-ECHO and that echo gets placed on the backbone, you are then the moderator. Rules should be posted once a month. In the event that you can no longer continue as the moderater for the echo you can either appoint a replacement or call for a vote. If we go to the voting the ZEC will coordinate the voting and will keep track of the ballots and then publsih the results. If a node drops from the network without appointing a new moderator, a vote will be taken for a new moderator. 7 ENFORCEMENT -------------- Enforcement of this section shall be under the provisions of General AtariNet policy. Complaints concerning Echomail violations defined under this section may be filed by the aggrieved individual, the conference moderator or by any level of Echomail Co-ordinator. All complaints made pursuant to this section must be made within 60 days of the date of occurrence or discovery. Complaints shall be filed under the provisions of AtariNet Policy, with a copy to the respective EC.